Many organizations deal with sensitive information, such as bank account information, health care information, credit information, academic information, etc. Such organizations often work under business and legal requirements that regulate how and when such information can be accessed by employees or contractors of the organization. For example, to protect a student's privacy a university must implement rules and regulations to prevent unauthorized viewing of a student's academic information. As another example, banks may have a policy to restrict a bank teller from viewing account information without a request from the customer to do so. Such viewing access may be termed a read-access and requirements may dictate appropriate situations for an employee to view data and proscribe inappropriate situations.
To help determine whether employees, agents, or customers have followed the read-access requirements and regulations, organizations may seek to determine who accessed the data. This is often accomplished through logging. But, in a large system numerous different applications may allow read-access to the data and if one application fails to properly log the read-access events, the log becomes incomplete. Having each application perform logging introduces complexity to the system and makes changes to the logging policies and regulations difficult. Furthermore, logging can often slow the performance of an application, frustrating employees and customers alike. For example, because read-access occurs more frequently than updates, a large bank may need to process tens of millions of read-access events in a typical workday. Adding even a few extra database transactions to each read event for such systems may noticeably degrade system performance.